1. Field of the Invention
This invention relates generally to the field of ROM-based system design, and more particularly, to the design of a system in which firmware modules or subroutines residing in ROM may be upgraded without re-spinning silicon.
2. Description of the Related Art
In computing, firmware typically refers to software embedded in a hardware device such as a read-only memory (ROM), most often implemented as an integrated circuit. Firmware can also reside in an erasable programmable read-only memory (EPROM) chip whose program may be modified by special external hardware, oftentimes utilizing optical means such as ultraviolet light, or an electrically erasable programmable read-only memory (EEPROM) chip whose program may be modified by special electrical external hardware different from the ultraviolet light used for configuring EPROMS (as mentioned above).
In general, EEPROMS have become fairly fast, large and comparatively inexpensive to manufacture, allowing them to compete with floppy disks, small hard disks and small CD-ROMs. One of the most popular forms of firmware storage that doesn't require any battery support is found in the form of flash memory or flash cards, which are usually inserted into various digital devices and are used for general storage.
In one aspect, firmware has evolved to also represent programmable content of a hardware device, which can consist of machine language instructions for a processor, or configuration settings for a fixed-function device, gate array or programmable logic device. Even though in many respects firmware is as much a software component of a working system as the operating system, unlike most modern operating systems, firmware rarely has a well established mechanism for updating itself to fix bugs or addressing functionality issues that are detected after a system that operates according to the firmware is shipped.
Thus, a typical common feature of present-day firmware is that it can be updated post-manufacturing without the need for additional hardware, either electronically, or by replacing a storage media such as a socketed memory chip, often using vendor-provided software, or a binary image file often referred to as a ROM image, which are uploaded onto existing hardware by a user. A ROM image typically contains a copy of the data from the ROM chip holding a computer's firmware. ROM images can also be used when developing embedded systems. Software which is being developed for an embedded system can be written to ROM files for testing on a standard computer before being written to a ROM chip for use in the embedded system.
In practical terms, firmware updates can improve the performance and reliability, indeed even the basic available functionality of a device, and many devices benefit from regular firmware updates. One of the most common devices to have regular firmware updates are recording devices such as optical media writers (DVD, CD, Blu-Ray), and as the various media technologies evolve, firmware updates can facilitate keeping hardware components compatible and up to date.
Comprehensively, it can be argued that many devices attached to modern systems operate as special-purpose computers of their own, running their own software, which is represented as firmware in a ROM within the device itself. Over the years, however, manufacturers have found that loading the firmware from the host system is both cheaper and more flexible. As a result, much of the hardware currently on the market is unable to function in any useful way until the host computer has loaded onto it the requisite firmware.
Finally, while cost and performance requirements combined with the developments described above have driven component vendors to adopt various replacements to the traditional ROM, including non-volatile media such as EEPROM and Flash, or SRAM solutions, such as the firmware loaded by an operating system device driver, in many systems a ROM may still provide the best and sometimes the only economically viable solution for storing firmware. This is especially true in systems where the firmware is stored on the same piece of silicon where the rest of the system is configured, as in certain embedded systems-on-a-chip (SOCs). Making modifications to firmware that is stored in an on-chip ROM typically requires a re-spin (metal layer change) to that device, making revisions to any such device expensive, time consuming, and difficult.
Certain architectures, for example Tiny Open Firmware (TOF—http://www.tinyboot.com/patches.html) allow for patching firmware residing in a ROM. Of course the ROM or the ROM content (code) is itself not changed. Instead, the code structure uses a RAM-based area of code space referred to as the binding table. All function calls for functions originally configured in the firmware residing in the ROM are actually made into the binding table. The entries in the table usually comprise jump instructions. They can be changed at will, to point to any subroutine. Essentially, different actions are bound to different token values.
The binding table makes it easy for other languages to invoke TOF functions. TOF may be used as a foundation on which to build a C application, allowing simple plug-and-play operation (and debugging) below the application level. In this case, the system may be considered a single object, with each subroutine representing a method. Almost all of these methods may be late-bound, but in an efficient way that doesn't impact run time much.
This makes patching any subroutine fairly straightforward. The evaluator loads boot code from a serial EEPROM at power up. This code causes patches to be compiled into RAM. It also changes the binding table to point to the new code. However, the program RAM requirement precludes many single-chip solutions, since most microcontrollers have insufficient or non-existent program RAM. While some 32-bit microcontrollers and some Digital Signal Processors (DSPs) could run TOF in single chip mode, TOF would have to be ported to them, a task that could prove expensive and possibly time consuming. Another method for generating an object file that facilitates patching and the introduction of new functionality for firmware stored in a ROM is found in U.S. Pat. No. 5,546,586.
While the above referenced solutions address the issue of patching firmware stored in a ROM, they can be costly and/or inefficient. For example, the need for jump tables with function pointers is space inefficient because function pointers occupy more space. In addition, all functions that may potentially require being patched need to be determined in advance, and changes to an original function would require a manual update to the Jump table with the corrected or new function address and/or pointers.
Other corresponding issues related to the prior art will become apparent to one skilled in the art after comparing such prior art with the present invention as described herein.